home *** CD-ROM | disk | FTP | other *** search
- config SELECT_MEMORY_MODEL
- def_bool y
- depends on EXPERIMENTAL || ARCH_SELECT_MEMORY_MODEL
-
- choice
- prompt "Memory model"
- depends on SELECT_MEMORY_MODEL
- default DISCONTIGMEM_MANUAL if ARCH_DISCONTIGMEM_DEFAULT
- default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT
- default FLATMEM_MANUAL
-
- config FLATMEM_MANUAL
- bool "Flat Memory"
- depends on !(ARCH_DISCONTIGMEM_ENABLE || ARCH_SPARSEMEM_ENABLE) || ARCH_FLATMEM_ENABLE
- help
- This option allows you to change some of the ways that
- Linux manages its memory internally. Most users will
- only have one option here: FLATMEM. This is normal
- and a correct option.
-
- Some users of more advanced features like NUMA and
- memory hotplug may have different options here.
- DISCONTIGMEM is an more mature, better tested system,
- but is incompatible with memory hotplug and may suffer
- decreased performance over SPARSEMEM. If unsure between
- "Sparse Memory" and "Discontiguous Memory", choose
- "Discontiguous Memory".
-
- If unsure, choose this option (Flat Memory) over any other.
-
- config DISCONTIGMEM_MANUAL
- bool "Discontiguous Memory"
- depends on ARCH_DISCONTIGMEM_ENABLE
- help
- This option provides enhanced support for discontiguous
- memory systems, over FLATMEM. These systems have holes
- in their physical address spaces, and this option provides
- more efficient handling of these holes. However, the vast
- majority of hardware has quite flat address spaces, and
- can have degraded performance from the extra overhead that
- this option imposes.
-
- Many NUMA configurations will have this as the only option.
-
- If unsure, choose "Flat Memory" over this option.
-
- config SPARSEMEM_MANUAL
- bool "Sparse Memory"
- depends on ARCH_SPARSEMEM_ENABLE
- help
- This will be the only option for some systems, including
- memory hotplug systems. This is normal.
-
- For many other systems, this will be an alternative to
- "Discontiguous Memory". This option provides some potential
- performance benefits, along with decreased code complexity,
- but it is newer, and more experimental.
-
- If unsure, choose "Discontiguous Memory" or "Flat Memory"
- over this option.
-
- endchoice
-
- config DISCONTIGMEM
- def_bool y
- depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) || DISCONTIGMEM_MANUAL
-
- config SPARSEMEM
- def_bool y
- depends on SPARSEMEM_MANUAL
-
- config FLATMEM
- def_bool y
- depends on (!DISCONTIGMEM && !SPARSEMEM) || FLATMEM_MANUAL
-
- config FLAT_NODE_MEM_MAP
- def_bool y
- depends on !SPARSEMEM
-
- #
- # Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's
- # to represent different areas of memory. This variable allows
- # those dependencies to exist individually.
- #
- config NEED_MULTIPLE_NODES
- def_bool y
- depends on DISCONTIGMEM || NUMA
-
- config HAVE_MEMORY_PRESENT
- def_bool y
- depends on ARCH_HAVE_MEMORY_PRESENT || SPARSEMEM
-
- #
- # SPARSEMEM_EXTREME (which is the default) does some bootmem
- # allocations when memory_present() is called. If this cannot
- # be done on your architecture, select this option. However,
- # statically allocating the mem_section[] array can potentially
- # consume vast quantities of .bss, so be careful.
- #
- # This option will also potentially produce smaller runtime code
- # with gcc 3.4 and later.
- #
- config SPARSEMEM_STATIC
- bool
-
- #
- # Architecture platforms which require a two level mem_section in SPARSEMEM
- # must select this option. This is usually for architecture platforms with
- # an extremely sparse physical address space.
- #
- config SPARSEMEM_EXTREME
- def_bool y
- depends on SPARSEMEM && !SPARSEMEM_STATIC
-
- config SPARSEMEM_VMEMMAP_ENABLE
- bool
-
- config SPARSEMEM_VMEMMAP
- bool "Sparse Memory virtual memmap"
- depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE
- default y
- help
- SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise
- pfn_to_page and page_to_pfn operations. This is the most
- efficient option when sufficient kernel resources are available.
-
- # eventually, we can have this option just 'select SPARSEMEM'
- config MEMORY_HOTPLUG
- bool "Allow for memory hot-add"
- depends on SPARSEMEM || X86_64_ACPI_NUMA
- depends on HOTPLUG && !(HIBERNATION && !S390) && ARCH_ENABLE_MEMORY_HOTPLUG
- depends on (IA64 || X86 || PPC64 || SUPERH || S390)
-
- comment "Memory hotplug is currently incompatible with Software Suspend"
- depends on SPARSEMEM && HOTPLUG && HIBERNATION && !S390
-
- config MEMORY_HOTPLUG_SPARSE
- def_bool y
- depends on SPARSEMEM && MEMORY_HOTPLUG
-
- config MEMORY_HOTREMOVE
- bool "Allow for memory hot remove"
- depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
- depends on MIGRATION
-
- #
- # If we have space for more page flags then we can enable additional
- # optimizations and functionality.
- #
- # Regular Sparsemem takes page flag bits for the sectionid if it does not
- # use a virtual memmap. Disable extended page flags for 32 bit platforms
- # that require the use of a sectionid in the page flags.
- #
- config PAGEFLAGS_EXTENDED
- def_bool y
- depends on 64BIT || SPARSEMEM_VMEMMAP || !NUMA || !SPARSEMEM
-
- # Heavily threaded applications may benefit from splitting the mm-wide
- # page_table_lock, so that faults on different parts of the user address
- # space can be handled with less contention: split it at this NR_CPUS.
- # Default to 4 for wider testing, though 8 might be more appropriate.
- # ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock.
- # PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes.
- #
- config SPLIT_PTLOCK_CPUS
- int
- default "4096" if ARM && !CPU_CACHE_VIPT
- default "4096" if PARISC && !PA20
- default "4"
-
- #
- # support for page migration
- #
- config MIGRATION
- bool "Page migration"
- def_bool y
- depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE
- help
- Allows the migration of the physical location of pages of processes
- while the virtual addresses are not changed. This is useful for
- example on NUMA systems to put pages nearer to the processors accessing
- the page.
-
- config PHYS_ADDR_T_64BIT
- def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT
-
- config ZONE_DMA_FLAG
- int
- default "0" if !ZONE_DMA
- default "1"
-
- config BOUNCE
- def_bool y
- depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM)
-
- config NR_QUICK
- int
- depends on QUICKLIST
- default "2" if SUPERH || AVR32
- default "1"
-
- config VIRT_TO_BUS
- def_bool y
- depends on !ARCH_NO_VIRT_TO_BUS
-
- config HAVE_MLOCK
- bool
- default y if MMU=y
-
- config HAVE_MLOCKED_PAGE_BIT
- bool
- default y if HAVE_MLOCK=y
-
- config MMU_NOTIFIER
- bool
-
- config DEFAULT_MMAP_MIN_ADDR
- int "Low address space to protect from user allocation"
- default 4096
- help
- This is the portion of low virtual memory which should be protected
- from userspace allocation. Keeping a user from writing to low pages
- can help reduce the impact of kernel NULL pointer bugs.
-
- For most ia64, ppc64 and x86 users with lots of address space
- a value of 65536 is reasonable and should cause no problems.
- On arm and other archs it should not be higher than 32768.
- Programs which use vm86 functionality or have some need to map
- this low address space will need CAP_SYS_RAWIO or disable this
- protection by setting the value to 0.
-
- This value can be changed after boot using the
- /proc/sys/vm/mmap_min_addr tunable.
-
-
- config NOMMU_INITIAL_TRIM_EXCESS
- int "Turn on mmap() excess space trimming before booting"
- depends on !MMU
- default 1
- help
- The NOMMU mmap() frequently needs to allocate large contiguous chunks
- of memory on which to store mappings, but it can only ask the system
- allocator for chunks in 2^N*PAGE_SIZE amounts - which is frequently
- more than it requires. To deal with this, mmap() is able to trim off
- the excess and return it to the allocator.
-
- If trimming is enabled, the excess is trimmed off and returned to the
- system allocator, which can cause extra fragmentation, particularly
- if there are a lot of transient processes.
-
- If trimming is disabled, the excess is kept, but not used, which for
- long-term mappings means that the space is wasted.
-
- Trimming can be dynamically controlled through a sysctl option
- (/proc/sys/vm/nr_trim_pages) which specifies the minimum number of
- excess pages there must be before trimming should occur, or zero if
- no trimming is to occur.
-
- This option specifies the initial value of this option. The default
- of 1 says that all excess pages should be trimmed.
-
- See Documentation/nommu-mmap.txt for more information.
-